clone() of a Bun.file() body no longer freezes what the Bun.file() answers or throws for a body that cannot be read - #44504

What does this PR do?

Fixes regressions on main from #42053, which is in no release. Replaces #43916.

const f = Bun.file(path);        // 5 bytes
new Response(f).clone();         // nothing reads a body
await Bun.write(path, "123456789");
f.size;                          // 1.4.2: 9, main: 5

After clone() of a body that is a Bun.file(path):

The same holds for Request.clone(), new Request(request), new Request(request, init) and new Request(url, response).

Cause. clone() has to know whether a path names something that yields its bytes once (a pipe, a terminal), because two Blobs over that would compete and the body is teed instead. #42053 asks with resolve_file_stat, which writes mode, seekable, max_size and last_modified on the Store. The body shares that Store with the Bun.file() it was made from, and nothing invalidates those fields, so clone() became one more call that freezes them. Separately, its rule was "tee whatever is not a regular file", and a tee over a directory cannot start.

Fix. store_yields_bytes_once (new, src/runtime/webcore/Blob.rs) answers for a Blob body, and Value::clone_with_readable_stream calls it in place of store_reads_repeatably.

• It keeps the mode it stats in a field of its own, mode_seen_by_clone, which nothing else reads. That is the fix for the stale answers and for procfs.
• It does not count a directory as yielding bytes once, by path or by fd, nor an fd that fstat fails for. There are no bytes to compete for, so the body is duped like a regular file and each body fails when it is read, as in 1.4.2. A failed clone() on main also leaves the original body used.
• For an fd it asks with resolve_file_stat, which is what the tee of an fd does next (to_readable_stream resolves the size). So the fstat only moves earlier, and an fd body is cached as on main.
• It still stats once per Store and still uses a stat that size or .body cached earlier, so clone() makes the same syscalls as on main.

Kept from #42053: a body over an fd, Bun.stdin, a FIFO by path and a terminal by path is teed, and a cloned Bun.file().stream() body keeps its type.

This is a partial fix. The arm for an unread .stream() body is not touched, so new Response(f.stream()).clone() still caches the stat: f.size and the rest stay stale after it, and a procfs .stream() body reads "". Taking the cache away there makes the bodies, which #42053 turns back into Blobs, behave in ways that neither 1.4.2 nor main has. Most of those are the right value, but console.log of a cloned slice().stream() body would print 0.0 ZB. That needs its own decision, so it is left out.

Nothing that main answers correctly after a clone() gets worse. Main has two answers right only because clone() writes the cache. Taking the write away alone would bring two older bugs back for code that clones, so they are fixed where they are:

• f.exists() stayed false for good once a stat had failed, with or without a clone() (await f.exists(), create the file, await f.exists()). get_exists_sync now stats again while no stat has succeeded.
• console.log of a Response or Request over Bun.file(p).slice(1, 4) prints 0.0 ZB until something stats the file, and on main clone() was that something. get_size_for_bindings now also accepts the mode clone() saw, so a cloned slice prints 3 bytes as on main.
• 0.0 ZB is u64::MAX, "unknown", run through the byte formatter. It is no longer printed: Response { and Request { carry no size when it is unknown. This is what makes the label right for a file that was deleted after the clone, where main prints the size it had.
• Printing such a body left the 0 of the failed stat in it. The next console.log would then have printed 0 KB, and text() read "" even after the file was created, with or without a clone(), on 1.4.2 too. get_size_for_bindings no longer keeps that 0.

A slice that was never cloned still has no size that console.log can print. It printed 0.0 ZB and now prints none. An empty file and a procfs file give the same stat, so cutting the slice to st_size gets one of them wrong, and I left that alone.

Why not #43916. It drops the stat for a Blob body, so a FIFO or a terminal given by path as the Blob is duped again and one body gets nothing. It stats uncached for a .stream() body, which costs 1000 newfstatat per 1000 clones of streams from one shared Bun.file(), where main pays 1. And it has the new behaviours described under "partial fix".

How did you verify your code works?

Tests, each run on a debug build of main, on this branch and on 1.4.2:

With the is_fd clause of store_yields_bytes_once disabled, the fd test is the only one in body-clone.test.ts that fails.

A differential run on Linux x64 of this branch against a debug build of main at the same base. It crosses 12 kinds of body (regular, empty, large, symlink, missing, directory, /dev/null, procfs, fd of a file, fd of a directory, fd that is not open, in-memory Blob), 4 earlier reads of the handle, 6 body forms, the 5 ways to clone plus 2 controls that do not clone, up to 12 changes to the file before or after the clone, and 29 observations, each in a fresh directory with a fresh handle. Two of them do a thing twice: print twice, and print and then read.

The rule it checks: a row that differs from main has to be correct, not merely what an older version did. Each scenario records what is on disk at that moment (existence, size, mtime, content). A changed row has to match that, or, where no such truth can be derived, what the same scenario answers without a clone(). A row where main matches the truth and this branch does not is reported as a regression on its own. There is none.

Extra syscalls for 1000 clones (strace, N=1000 minus N=0), newfstatat / fstat / openat:

Unchanged from main: 48 cases over a FIFO, /dev/stdin, Bun.stdin and a file replaced by a FIFO (3 runs each), /dev/tty and /dev/stdin under a pty, and /dev/null and /dev/zero slices.

Suites on the debug build, no failures: body-clone, body, response, blob, blob-write, body-stream, request, FormData, bun-file, bun-file-exists, inspect, console-log, bun-serve-file, bun-serve-static. In fetch.test.ts and bun-write.test.js one test each fails with EFBIG, here and on main, because I ran them under a 200 MB file size limit. bun run rust:check-all passes for x86_64-pc-windows-msvc and aarch64-apple-darwin.

Not verified: Windows and macOS at runtime. The two fd tests are skipped on Windows.